home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-telnet-interoperability-00.txt < prev    next >
Text File  |  1993-04-08  |  9KB  |  230 lines
  1.  
  2.  
  3.  
  4. Network Working Group                    Internet Engineering Task Force
  5. Internet-Draft                                      Telnet Working Group
  6.                                                                D. Borman
  7.                                                      Cray Research, Inc.
  8.                                                               April 1993
  9.  
  10.  
  11.            Telnet Environment Option Interoperability Issues
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet Draft.  Internet Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its Areas,
  17.    and its Working Groups. Note that other groups may also distribute
  18.    working documents as Internet Drafts.
  19.  
  20.    Internet Drafts are draft documents valid for a maximum of six
  21.    months. Internet Drafts may be updated, replaced, or obsoleted by
  22.    other documents at any time.  It is not appropriate to use Internet
  23.    Drafts as reference material or to cite them other than as a "working
  24.    draft" or "work in progress."
  25.  
  26.    Please check the 1id-abstracts.txt listing contained in the
  27.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  28.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  29.    current status of any Internet Draft.
  30.  
  31. 1.  Overview
  32.  
  33.    RFC 1408 [1], the specification for the Telnet Environment Option,
  34.    specifies definitions for VAR and VALUE that are reversed from the
  35.    BSD implementation of the Telnet Environment option.  Since the BSD
  36.    implementation was the reference implementation that the RFC was
  37.    supposed to document, and is the base for many existing
  38.    implementations, there exists an interoperability problem between
  39.    implementations with conflicting definitions for VAR and VALUE.
  40.  
  41.    This document describes a method for allowing implementors to ensure
  42.    that their implementation of the Environment option will be
  43.    interoperable with as many other implementations as possible, by
  44.    providing a set of heuristics that can be used to help identify which
  45.    definitions for VAR and VALUE are being used by the other side of the
  46.    connection.
  47.  
  48. 2.  Client Telnet: Parsing a SEND
  49.  
  50.    The SEND suboption should only contain VAR and USERVAR commands.  It
  51.  
  52.  
  53.  
  54. Telnet Working Group      Expires October 1993                  [Page 1]
  55.  
  56. Internet-Draft    Environment Option Interoperability         April 1993
  57.  
  58.  
  59.    should never contain a VALUE.  If while parsing a SEND suboption, a
  60.    VALUE is encountered, the client should assume that the server has
  61.    reversed values for VAR and VALUE, and from that point on the client
  62.    should reverse those values, both in parsing the rest of the SEND
  63.    suboption, and when generating an IS or INFO suboption.  If both
  64.    VALUE and VAR commands are encountered, the SEND command is not well
  65.    formed, and it is implementation dependent as to what will happen.
  66.  
  67.    If there are not VAR or VALUE commands in the SEND suboption, then
  68.    the client cannot know what values the server is expecting for VAR
  69.    and VALUE.  In this case, it should just assume that the server has
  70.    the correct definitions, and use the correct values for VAR and
  71.    VALUE.
  72.  
  73. 3.  Server Telnet: Parsing an IS or INFO
  74.  
  75.    The IS or INFO in a suboption can only be legally followed by either
  76.    a VAR or a USERVAR.  If an IS or INFO is immediately followed by a
  77.    VAR, then it can be assumed that the client has the correct
  78.    definitions for VAR and VALUE.  If the IS or INFO is immediately
  79.    followed by a VALUE, then it can be assumed that the client has
  80.    reversed definitions for VAR and VALUE, and from that point on the
  81.    server should assume that the VALUE and VAR definitions are reversed.
  82.  
  83.    If the IS or INFO is immediately followed by a USERVAR, further
  84.    hueristics must be applied to determine what are the client
  85.    definitions for VAR and VALUE. This is because it is legal for a
  86.    USERVAR to be followed by either a VAR or a VALUE.  A VALUE after a
  87.    USERVAR gives the value for the USERVER.  A VAR after a USERVAR
  88.    implies that the USERVAR is undefined.
  89.  
  90.    The next thing to do is to scan the entire suboption, looking for two
  91.    consecutive instances of VAR or VALUE, or for a VAR or VALUE that is
  92.    empty.  It is not legal for a suboption to contain two VALUEs without
  93.    an intervening VAR or USERVAR, and it is also not legal for a
  94.    suboption to contain an empty VAR.  Thus, if two consecutive VARs or
  95.    an empty VALUE can be found, it can be assumed that the client that
  96.    generated the suboption uses the correct definitions for VAR and
  97.    VALUE.  If two consecutive VALUEs or an empty VAR can be found, then
  98.    it can be assumed that the client that generated the suboption has
  99.    reversed definitions for VAR and VALUE, and from that point on the
  100.    server should assume that the VAR and VALUE definitions are reversed.
  101.  
  102.    If things are still in doubt, the next test that can be applied is to
  103.    count up how many VARs, USERVARs and VALUEs were received.
  104.    (Consecutive USERVARs without an intervening VALUE or VAR should only
  105.    be counted as one.) Because a VALUE can only follow a VAR or a
  106.    USERVAR, there can never be more VALUEs than the sum of VARs and
  107.    USERVARs, and if all VARs and USERVARs have values, then there will
  108.    be exactly as many VALUEs as there are VARs and USERVARs.  If the
  109.  
  110.  
  111.  
  112. Telnet Working Group      Expires October 1993                  [Page 2]
  113.  
  114. Internet-Draft    Environment Option Interoperability         April 1993
  115.  
  116.  
  117.    number of VARs and USERVARs is the same as the total number of
  118.    VALUEs, then the client has correct definitions for VAR and VALUE.
  119.    If the number of VALUEs and USERVARs is the same as the total number
  120.    of VARs, then the client has reversed definitions for VAR and VALUE.
  121.  
  122.    If the number of VALUEs is more than the sum of VARs and USERVARs, it
  123.    can be assumed that the client has reversed definitions of VAR and
  124.    VALUE, and if there are more VARs than USERVARs and VALUEs, then it
  125.    can be assumed that the client has the correct definitions for VAR
  126.    and VALUE.  However, in order to get to this step, it has already
  127.    been determined that there are no consecutive VARs and VALUEs.  A
  128.    little math will show that this means that the number of VALUEs will
  129.    never exceed the sum of VARs and USERVARs, and the number of VARs
  130.    will never exceed the sum of VALUEs and USERVARs.  Hence, this check
  131.    is redundant and can be skipped.
  132.  
  133.    If things are still in doubt, the values of the VAR commands can be
  134.    checked to see if they do indeed specify well known variables.  If
  135.    any of them do, then the client is probably using the correct
  136.    definitions for VAR and VALUE.  Otherwise, if any of the VALUEs
  137.    contain well know variable names, then the client probably has
  138.    reversed definitions for VAR and VALUE.
  139.  
  140.    If all the above heuristics fail, then the server has done all it can
  141.    to determine what type of client it is, and it should just be assumed
  142.    that the client is using the correct definitions for VAR and VALUe.
  143.  
  144. 4.  Client Summary
  145.  
  146.  
  147.        The SEND suboption contains only VAR and USERVAR commands.
  148.            The server is ok.
  149.        The SEND suboption contains VALUE commands.
  150.            The server is reversed.
  151.        No VAR or VALUE commands are found.
  152.            Assume the server is ok.
  153.  
  154.  
  155. 5.  Server Summary
  156.  
  157.  
  158.        IS/INFO is followed by VAR.
  159.            The client is ok.
  160.        IS/INFO is followed by VALUE.
  161.            The client is reversed.
  162.        There are two consecutive VARs.
  163.            The client is ok.
  164.        There are consecutive VALUEs.
  165.            The client is reversed.
  166.        There is an empty VALUE.
  167.  
  168.  
  169.  
  170. Telnet Working Group      Expires October 1993                  [Page 3]
  171.  
  172. Internet-Draft    Environment Option Interoperability         April 1993
  173.  
  174.  
  175.            The client is ok.
  176.        There is an empty VAR.
  177.            The client is reversed.
  178.        The number of USERVARs and VARs is equal to the number of VALUEs.
  179.            Assume the client is ok.
  180.        The number of USERVARs and VALUEs is equal to the number of VARs.
  181.            Assume the client is reversed.
  182.        There are VARs with names that are well known.
  183.            Assume the client is ok.
  184.        There are VALUEs with names that are well known.
  185.            Assume the client is reversed.
  186.        Anything else.
  187.            Assume the client is ok.
  188.  
  189. References
  190.  
  191.    [1] Borman, D., editor, "Telnet Environment Option", RFC 1408, Cray
  192.        Research, Inc., January 1993.
  193.  
  194. Author's Address
  195.  
  196.    David A. Borman
  197.    Cray Research, Inc.
  198.    655F Lone Oak Drive
  199.    Eagan, MN 55123
  200.  
  201.    Phone: (612) 452-6650
  202.  
  203.    Mailing List: telnet-ietf@CRAY.COM
  204.    EMail: dab@CRAY.COM
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228. Telnet Working Group      Expires October 1993                  [Page 4]
  229.  
  230.